As is well known in the art, within a multiprocessor computer system, several command instructions are processed at the same time by a plurality of microprocessors, also known as coprocessors or processors. Each processor may simultaneously process multiple series of command instructions, or “threads,” wherein each command instruction is processed by one processor thread. The routing of commands to the threads is controlled by a central manager. Each processor/thread operates independently from all the other processors/threads. Thus, as the software processes a command, the software has no knowledge of other instructions which have been, are being, or will be processed. Each processor executes the instructions in a sequential manner but independently and in parallel to the other processors. In order to ensure thorough testing of a multiprocessor computer system, many different techniques can be used.
Multiprocessor systems present a verification problem in the sense that there are countless scenarios that can be run. Traditionally, even in a self checking environment, scenarios are largely hard coded (i.e., all test input stimulus and sequences are pre-defined at run time), often referred to as “directed tests.” Alternatively, scenarios may be fully randomized (i.e., test input stimulus and sequences are arbitrarily chosen at run time). The hard coded scenarios can be time consuming to write, and may still only cover a fraction of the actual function. In addition, as the number of processor/threads used in the simulation increases, the complexity of the desired test cases increases. Typically, a number of hard coded test cases are written to flush out the major functions, and then randomized test cases are written to cover the rest (including corner cases). The problem is that fully randomized test cases become quite complicated to manage in terms of ensuring complete test coverage. Additionally, a problem with fully randomized test cases is the possibility of selecting a sequence of commands that are invalid or of little testing value. Checking for these undesired sequences and correcting them increases the complexity of the test environment and severely restricts the random sequences that can be applied to the design under test.